home *** CD-ROM | disk | FTP | other *** search
/ SGI Developer Toolbox 6.1 / SGI Developer Toolbox 6.1 - Disc 4.iso / perfTuning / gldebug.notes < prev    next >
Encoding:
Text File  |  1994-08-02  |  8.3 KB  |  221 lines
  1.  
  2. Great tool for a quick examination of a program.  Only tool if you do not
  3. have access to the source.  Useful for a sanity check of the appilcation.
  4. Is the programmer telling the truth about their code. 
  5.  
  6. o GLdebug can be used both to debug and to tune:
  7.     - tells you what graphics calls are being issued 
  8.     - look for lots of mode changes, or unnecesssary mode settings
  9.     - verify subpixel(1); glcompat(GLC_OLDPOLYGON, FALS);
  10.     - check on:
  11.     shademodel(FLAT/GOURAUD)
  12.     infinite vs lights or LOCALVIEWER set in the Light Model
  13.     two sided lighting
  14.     mode changes: 
  15.         frequent calls to shademodel, zbuffer, blendfunction    
  16.         use of lmdef instead of lmcolor
  17.     - check for duplicate data 
  18.     (often seen in normals and colors with flat-shading)
  19.     - or unnecessary vertex bindings,
  20.         such as uneeded per-vertex colors or normals for a flat shaded object.
  21.     * must be single process to run gldebug
  22.     * using ignore files will simplify gldebug output
  23.  
  24.  
  25. o What warning message are printed?
  26.  
  27. Explanation of Options:
  28. -----------------------
  29.      -h              no history output.
  30. [run this option when you only want to see use the Stateviewer]
  31.  
  32.      -w              no warning output.
  33.  
  34.      -e              no error output.
  35.  
  36.      -f              no fatal error output.
  37.  
  38.  
  39.  
  40.      -c              do not run Controller.
  41.  
  42.      -s              do not run Stateviewer.
  43. [run these options when you only want to see the output history, i.e. when
  44. you are looking for known bad habits which degrade performance.  It may be
  45. useful to generate a history file in one pass then run the Stateviewer while 
  46. examining the output.] 
  47.  
  48.      -C              generate C code in history file.
  49. [this is not very useful as the code never looks like the application.
  50. One may be able to reconstruct a bug without copying an unmanagably large
  51. size of application code.  Also useful for producing a benchmark of the code
  52. in the application.  This does not produce code which will compile.]
  53.  
  54.      -F              flush output buffer to history file after each GL call.
  55.  
  56.      -p wait         profile (output the number of times each GL function is
  57.                      called).  wait is the number of GL calls wait between
  58.                      each profile write to file.  Profile output goes to
  59.                      GLdebug.count.
  60.  
  61.      -i filename     ignore the GL functions listed in filename when writing
  62.                      output.  filename should contain GL function names listed
  63.                      one per line.
  64. [very useful for supressing commands which carry lots of data like texdef, 
  65. defpattern, v3f, etc.]
  66.  
  67.      -o filename     send history trace output to filename. Default is
  68.                      GLdebug.history.
  69.  
  70.      -O              send history trace output to stdout. This overrides -o
  71.                      filename.
  72. [not very useful, history files are always big]
  73.  
  74.  
  75. o Useful alias: gldebug -i ~/gldignore -sF
  76.     gldignore:
  77.     -----------
  78.     qread
  79.     getmatrix
  80.     defpattern
  81.     texdef
  82.  
  83. Taking a GLdebug Trace:
  84. -----------------------
  85.     gldebug session to grab one frame:
  86.         - start up gldebug
  87.         - turn of output and breakpoints
  88.         - set breakpoint at swapbuffers
  89.         - go to interesting frame
  90.         - turn on breakpoints
  91.         > will stop at swapbuffers
  92.         - turn on output
  93.         - continue
  94.         > will stop at swapbuffers, outputing one full scene to GLdebug.history
  95.         - quit and look at output
  96.         
  97.         * note:  grabbing one  frame will show stuff set that frame but will
  98.             not reflect modes that were set previously.
  99.             therefore, it is best ot have a program that can come up in the
  100.             desired location and with the desired modes and then grab
  101.             the first 2 frames: 1 for initialization, one for
  102.             continued drawing.
  103.  
  104.  
  105. EXAMPLE:
  106. --------
  107.  
  108. > Vince,
  109. > 
  110. >     Here is a chunck of the output.  Note that a number of different 
  111. > techniques are used for drawing the models within the scene.  So this
  112. > is only representative of a subset of the drawing (e.g. I don't even
  113. > know if any of the models in this section have textures turned on).
  114. > 
  115.  
  116. While working with Frank he thought that their code was finely tuned for
  117. VGX.  He said something about a team of programmers working on the code
  118. for 10 man years.  At first i had little  confidence that we could improve his
  119. code, but i think we have found room for improvement.  
  120.  
  121. First as you both know if you move an app from the VGX to RE and see no 
  122. improvement it probably means that you have a CPU bottleneck or something
  123. really stupid is being done in the graphics code.  Unfortunately, we do not 
  124. know what all of those "stupid" things are on RE yet.  
  125. Also, in the demo that he is running there was no texture mapping.  
  126. i am not surprise to learn that there was little improvement for non-texture
  127. mapped primitives.  For standard phong lighted, Z-buffered, non-textured 
  128. primitives the performance is about the same.  The flat-shaded tmesh 
  129. performance is exactly the same.  The Gouraud shaded tmesh performance is 
  130. about 10% higher on a RE.
  131. The biggest improvement comes with independent Gouraud shaded quads, about 33%.
  132. Turn on texturing and you get a big win.
  133.  
  134. i helped Frank generate one frame of gldebug output and asked him to send
  135. me the file.  A quick glance at the data reveals 3 sets of superfluous calls 
  136. to the GL only 2 of which could impact performance.  The improvements made here
  137. should result in improved performance on both VGX and RE since it will reduce 
  138. the CPU bottleneck.
  139.  
  140.     1) n3f
  141.     2) lmbind
  142.     3) misc.
  143.     
  144. 1) The biggest problem is with duplicated normals. One trick to remember is that
  145. the hardware caches the normal and provides a copy with any 
  146. subsequent vertexes that are sent without normals while lighting is enabled.
  147. If you look at the tmeshes you will notice 50 - 90+ % of the normal data
  148. is duplicated.  Note i suppressed the gldebug output of v3f commands. 
  149. If you look at the first FLAT shaded tmesh which has 12 vertexes you will 
  150. see that 12 identical normals are being copied.  That is 50% more data than
  151. necessary.  Since lighting was enabled the same normal was also transformed 
  152. for each copy.  Furthermore, if multiple objects share the same normal it need 
  153. only be sent once.  This change may require rebuilding of the database.
  154.  
  155. 2) It appears that every new lmbind call is preceded by a call to 
  156. lmbind(MATERIAL, 0) which disables lighting.  This is only necessary if they
  157. wish to draw an unlighted object.  This is inefficeint toggling of modes.  The
  158. RealityEngine is very sensitive to mode changes.  Remove that lmbind.
  159.  
  160. 3) There appear to be calls to things that are never used.
  161. e.g. getmatrix(), getpattern(), the query calls can be expensive because
  162. they are copying data back to the host or often have to go into feedback mode.
  163.  
  164. Finally, it would be helpful to see some prof/pixie output from their program
  165. to verify this.  If we are truely experiencing a CPU botteneck then you should
  166. see gl_i_v3f and gl_i_n3f listed at the very top of the pixie readings.
  167.  
  168. good luck and i hope this helps,
  169. vince
  170.  
  171. > getpattern();
  172. > getmatrix(OUT);
  173. > lmbind(MATERIAL, 0);
  174. > lmbind(MATERIAL, 5);
  175. > shademodel(GOURAUD);
  176. > bgntmesh();
  177. > n3f({1.000000, 0.000000, 0.000000});
  178. > n3f({1.000000, 0.000000, 0.000000});
  179. > n3f({0.500000, 0.797443, -0.337763});
  180. > n3f({0.500000, 0.797443, -0.337763});
  181. > n3f({-0.500000, 0.797443, -0.337763});
  182. > n3f({-0.500000, 0.797443, -0.337763});
  183. > n3f({-1.000000, 0.000000, 0.000000});
  184. > n3f({-1.000000, 0.000000, 0.000000});
  185. > n3f({-0.500000, -0.797443, 0.337763});
  186. > n3f({-0.500000, -0.797443, 0.337763});
  187. > n3f({0.500000, -0.797443, 0.337763});
  188. > n3f({0.500000, -0.797443, 0.337763});
  189. > n3f({1.000000, 0.000000, 0.000000});
  190. > n3f({1.000000, 0.000000, 0.000000});
  191. > endtmesh();
  192.  
  193. > lmbind(MATERIAL, 0);
  194. > lmbind(MATERIAL, 6);
  195. > shademodel(FLAT);
  196. > bgntmesh();
  197. > n3f({-1.000000, 0.000000, 0.000000});
  198. > n3f({-1.000000, 0.000000, 0.000000});
  199. > swaptmesh();
  200. > n3f({-1.000000, 0.000000, 0.000000});
  201. > swaptmesh();
  202. > n3f({-1.000000, 0.000000, 0.000000});
  203. > swaptmesh();
  204. > n3f({-1.000000, 0.000000, 0.000000});
  205. > swaptmesh();
  206. > n3f({-1.000000, 0.000000, 0.000000});
  207. > swaptmesh();
  208. > n3f({-1.000000, 0.000000, 0.000000});
  209. > swaptmesh();
  210. > n3f({-1.000000, 0.000000, 0.000000});
  211. > swaptmesh();
  212. > n3f({-1.000000, 0.000000, 0.000000});
  213. > swaptmesh();
  214. > n3f({-1.000000, 0.000000, 0.000000});
  215. > swaptmesh();
  216. > n3f({-1.000000, 0.000000, 0.000000});
  217. > swaptmesh();
  218. > n3f({-1.000000, 0.000000, 0.000000});
  219. > endtmesh();
  220.  
  221.